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Foreword 



This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the possible protocol architectures for transport of SS7 signalling protocols in Core 
Network. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

2.1 Normative references 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] ITU-T Recommendation Q.701: "Functional description of the message transfer part (MTP) of 

signalling system No. 7". 

[3] ITU-T Recommendation Q.702: "Signalling data link". 

[4] ITU-T Recommendation Q.703: "Signalling link". 

[5] ITU-T Recommendation Q.704: "Signalling network functions and messages". 

[6] ITU-T Recommendation Q.705: "Signalling network structure". 

[7] ITU-T Recommendation Q.706: "Message transfer part signalling performance". 

[8] RFC 2960: "Stream Control Transmission Protocol" . 

[9] ITU-T Recommendation G.804: "ATM cell mapping into Plesiochronous Digital Hierarchy 

(PDH)". 

[10] ITU-T Recommendation 1. 112: "Vocabulary of terms for ISDNs". 

[II] ITU-T Recommendation 1.361: "BTSDN ATM layer specification". 

[12] ITU-T Recommendation 1.363.5: "B-ISDN ATM Adaptation Layer specification: Type 5 AAL". 

[13] ITU-T Recommendation Q.21 10: "B-ISDN ATM adaptation layer - Service specific connection 

oriented protocol (SSCOP)". 

[14] ITU-T Recommendation Q.2140: "B-ISDN ATM adaptation layer - Service specific coordination 

function for signalling at the network node interface (SSCF at NNI)". 

[15] ITU-T Recommendation Q.2210: "Message transfer part level 3 functions and messages using the 

services of ITU-T Recommendation Q.2140". 

[17] RFC 3309: "SCTP Checksum Change". 

[18] RFC 4666:Signahng System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer 

(M3UA)". 
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[19] RFC 4165: Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -User Peer-to-Peer 

Adaptation Layer (M2PA)". 

2.2 Informative references 

[16] RFC 2719: "Framework Architecture for Signalling Transport". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

(no further terms defined) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AAL5 ATM Adaptation Layer type 5 

ATM Asynchronous Transfer Mode 

IP Internet Protocol 

MTP Message Transfer Part 

MTPl Message Transfer Part layer 1 

MTP2 Message Transfer Part layer 2 

MTP3 Message Transfer Part layer 3 

M2PA Message Transfer Part 2 -User Peer-to-Peer Adaptation Layer 

M3UA MTP3-User Adaptation 

PDH Plesiochronous Digital Hierarchy 

SSCF Service Specific Coordination Function 

SSCOP Service Specific Connection Oriented Protocol 

SCCP Signalling Connection Control Part 

SCTP Stream Control Transmission Protocol 

SDH Synchronous Digital Hierarchy 

TCAP Transaction Capabilities Application Part 



Introduction 



The Core Network enables the transport of SS7 signalling protocols between two entities by means of different 
underlying networks (e.g. MTP -based, IP-based or ATM-based). 

The transport of SS7 signalling protocol messages of any protocol layer that is identified by the MTP level 3 layer, in 
SS7 terms, as a user part (MTP3-user) shall be accomplished in accordance with the protocol architecture defined in the 
following sub-clauses. The list of these protocol layers includes, but is not limited to. Signalling Connection Control 
Part (SCCP). 

The transport of protocols which can be identified as SCCP-users, like for example TCAP, and in turn the transport of 
TCAP -users like MAP and CAP, shall also be accomplished in accordance with the defined protocol architectures, 
since their protocol messages are transferred as SCCP payload. 
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5 Protocol architectures 

5.1 Protocol architecture in the case of MTP-based SS7 
signalling transport network 

The transport of an MTP3-user signalling messages shall be accomplished in accordance with the relevant ITU-T 
Recommendations [2], [3], [4], [5], [6], [7]. 

The protocol architecture applicable in the case of MTP-based SS7 signalling transport network is shown in Figure 
5.1/1 



MTP3-User 



MTP3 



MTP2 



MTPl 



Figure 5.1/1 : Protocol architecture in the case of MTP-based SS7 signalling transport network 

5.2 Protocol architecture in the case of IP-based SS7 signalling 
transport network 

5.2.1 M3UA 

The transport of an MTP3-user signalling messages shall be accomplished in accordance with the architecture defined 
by the "Framework Architecture for Signalling Transport" [16], by "Stream Control Transmission Protocor'[8] and by 
the IETF document available in Annex A. An implementation of SCTP to this document shall use the checksum method 
specified in RFC 3309 [17] instead of the method specified in RFC 2960 [8]. 

The M3UA protocol architecture applicable in the case of IP -based SS7 signalling transport network is shown in Figure 
5.2/1 
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Figure 5.2/1 : M3UA architecture in the case of IP-based SS7 signalling transport network 

The definition of the use of M3UA in 3GPP core network is provided in Annex A to this specification. 

5.2.2 MTP3-M2PA 

An MTP3 signalling message can also be transported by M2PA, which shall be accomplished in accordance with IETF 
RFC4165[19]. 

The M2PA protocol architecture applicable in the case of IP -based SS7 signalling transport network is shown in Figure 
5.2/2 
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Figure 5.2/2: M2PA architecture in thie case of IP-based SS7 signalling transport network 

The definition of the use of M2PA in 3GPP core network is provided in Annex B to this specification. 



5.3 Protocol architecture in the case of ATlVJ-based SS7 
signalling transport network 

The transport of an MTP3-user signalHng messages shall be accomplished in accordance with the relevant ITU-T 
Recommendations [9], [10], [11], [12], [13], [14], [15] 

The protocol architectures applicable in the case of ATM-based SS7 signalling transport network are shown in Figure 
5.3/1. 
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Figure 5.3/1 : Protocol architectures in the case of 
ATM-based SS7 signalling transport network 
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Annex A (Normative): 

The use of M3UA in 3GPP networks 

A.1 Scope 

This annex defines the application of M3UA in 3GPP core networks. The purpose of the Annex is to ensure the 
interoperability of different implementations of M3UAs used by different operators and vendors. This is achieved by: 

Clarifying certain concepts which are used in RFC 4666; 

Defining those features in RFC 4666 for which support is mandatory; 

Defining those features in the RFC 4666 for which support is optional; 

Defining those features in RFC 4666 which shall not be used; 

The specification is intended for interfaces between network domains, however, it can also be used inside one network 
domain, and constitutes a minimum set of M3UA requirements to be supported between IP nodes and between IP nodes 
and SGW nodes in a 3GPP network. 

A.2 Introduction 

M3UA may be used on a number of interfaces in a 3GPP core network. The annex is intended for the interface called A 
and C in figure 1 . A is the Interface between two IP nodes that are equipped with SCTP, M3UA and a M3U A user. 
Examples of M3UA user are BICC, H.248, SCCP and ISUP. The interface can be used inside one network domain but 
also to interconnect network domains. Interface B can be used between network domains and inside network domains. 
Interface B is not in the scope for this annex, however, use of Q.701-Q.705 or Q.2210 on interface B is already 
standardised; in addition, M2PA is also endorsed for interface B in accordance with Annex B. Interface C is the 
interface between a node including SCTP, M3UA and a M3UA user and a node including SCTP, M3UA and 
M3UAsignalling gateway functions.. This interface is inside one network domain. 

Interfaces A and C are similar. The main difference is that interface C shall also allow for interworking with the SS 7 
network and therefore provides functions for the interworking. 

The signalling gateways in this picture are pure MTP3/3B-M3UA signaling gateways. They do not include any M3UA 
users. Still there could be a node including an M3UA user (e.g. SCCP functions) and a M3UA signalling gateway 
functions. In that case, the node will support all the interfaces A, B and C. 
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Figure 1 : Use of M3UA in 3GPP core networl< 



A.3 Protocol conformance to RFC 4666 

A minimum implementation shall support sections marked mandatory in the table below. It shall be possible to 
configure all implementations to interoperate (no error messages returned) with the minimum set. 

The table below makes comment to the sections in RFC 4666. In the comment column the following terms are used: 

Mandatory: When support of text in a section is marked mandatory: 

o On an information element, message or message class, it means that a receiver shall understand the 
information element, message or message class and carry out the requested action. 

o For a procedure, it means that the procedure is mandatory to be carried out by the involved network 
elements. 

Optional: When support of the text in a section is marked optional the feature involved is only guaranteed to 
work between peer entities which are subject to a bilateral agreement between operators of those entities. If one 
end uses an optional message or information element and the other does not support it, then either a silent 
discard takes place of an information element as a part of the message or the message is discarded and an error 
message is returned. This is described as part of the handling of the optionality in the table. 

- Excluded: This means that the feature shall not be used in a 3GPP environment 

Descriptive text means that the section does not include any requirements for this specification. 

Note: The word "heading" means that the section consists only of subordinate sections. 

The comments column also defines the behaviour of a minimum implementation if it does not support a message or an 
information element in a mandatory message. 
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Section number in IVISUA 
RFC 


Comments 


Abstract 


Descriptive text 


1. Introduction 


Descriptive text 


1.1 Scope 


Descriptive text 


1.2 Terminology 


Descriptive text. 


1 .3 IVISUA overview 


Descriptive text. 


1 .4 Functional area 


Descriptive text. 


1 .5 Sample Configurations 


Descriptive text 


1.6 Definition of IVI3UA 
Boundaries 


Descriptive text 


2 Conventions 


Descriptive text 


3. I\/I3UA Protocol Elements 


Mandatory 


3.1 Common message 
header 


Mandatory 


3.1.1 M3UA Protocol 
Version: 


The version number field shall be set to 1 


3.1 .2 Message classes and 
types 


The values are classified as follow 
0-4 Mandatory 
5-8 Excluded 

9 Optional (Routing Key Management (RKM) Messages) 

10 to 255 Excluded 


3.1.2 (Management (MGMT) 
message) 


The values are classified as follow 

Mandatory 

1 Optional (Notify). When received and not supported the 
message maybe silently discarded. 

2-255 Excluded 


3.1 .2 (Transfer messages) 


The values are classified as follow 

Excluded 

1 Mandatory 

2 to 255 Excluded 


3.1.2 (Signalling network 
management (SSNM) 
messages) 


The values are classified as follow 
Excluded 
1-6 Mandatory 

7- 255 Excluded. 


3.1.2 (ASP State 
Maintenance (ASPSM) 
Messages) 


The values are classified as follow 
Excluded 
1-6 Mandatory 
7-255 Excluded 


3.1.2 (ASP Traffic 
Maintenance (ASPTM) 
Messages) 


The values are classified as follow 
Excluded 
1-4 Mandatory 
5 to 255 Excluded 


3.1.2 (Routing key 
management (RKM)) 
messages 


Optional 

If any of these messages is received and not supported an error message with the error 

code 0x04 (Unsupported message type) shall be sent 


3.1.3 Reserved 


Mandatory 


3.1.4 Message length 


Mandatory 
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Section number in lUISUA 
RFC 


Comments 


3.2 Variable Length 
Parameter Format Common 
Parameters: 


The values are classified as follows 

0x0000-- 0x0003, 0x0005, 0x0008, OxOOOa, OxOOOe, OxOOOf, 0x0010 0x0014— 0x01 ff 
Excluded 

0x0007, 0x0009, OxOOOc and 0x0012 Mandatory 

0x0004 optional (INFO String) if received and not supported the message is processed 
but the optional information element is silently discarded, 

0x0006 optional (Routing Context if received and not supported the message is 
processed but the optional information element is silently discarded, 
OxOOOb optional (Traffic Mode Type) if received and not supported the message is 
processed but the optional information element is silently discarded, 

0x001 1 (ASP Identifier) if received and not supported the message is processed but the 
optional information element is silently discarded, 

0x0012 Affected point code is mandatory. The support of value in the mask field is 
mandatory. All other values is outside the scope of this annex. 

0x0013 (Correlation ID) if received and not supported the message is processed but the 
optional information element is silently discarded. 


3.2 Variable Length 
Parameter Format M3UA 
Specific Parameters 


The values are classified as follows 

0x0201 , 0x0202, 0x0203, 0x021 1 , 0x020d and 0x0214 to Oxffff Excluded 

0x0204-0x0205, 0x0210 Mandatory 

0x0200 optional (Network Appearance) if received and not supported the message is 
processed but the optional information element is silently discarded, 

0x0206 Optinal (Concerned Destination). If received and not supported the message is 
processed but the optional information element is silently discarded. 

0x0207 (Routing Key), 0x0208 (Registration Result), 0x0209 (Deregistration Result) 
0x020a (Local Routing Key Identifier), 0x020b (Destination Point Code), 0x020c (Service 
Indicators) 0x020d (Subsystem Numbers), 0x020e (Originating Point Code List), 0x020f 
(Circuit Range), 0x0212 (Registration Status), 0x0213 (Deregistration Status) are 
parameters in optional message, and therefore no action is specified. 


3.3 Transfer messages 


These messages are mandatory at the interfaces A and C. 


3.3.1 Payload Data Message 
(DATA) 


The parameters Network Appearance, Routing Context, Correlation ID are optional 
The parameter Protocol data is mandatory. 


3.4 SS7 signalling network 
management messages 


Heading 


3.4.1 Destination Unavailable 
(DUNA) 


The message is mandatory at the interface C. 

The parameters Network Appearance, Routing Context, and INFO String are optional 

The parameter Affected Point Code is mandatory 


3.4.2 Destination Available 
(DAVA) 


The message is mandatory at the interface C 

The parameters Network Appearance, Routing Context, and INFO String are optional. 

The parameter Affected Point Code is mandatory 


3.4.3 Destination State Audit 
(DAUD) 


The message is mandatory at the interface C 

The parameters Network Appearance, Routing Context, and INFO String are optional. 

The parameter Affected Point Code is mandatory 


3.4.4 Signalling Congestion 
(SCON) 


The message is mandatory at the interface C 

The parameters Network Appearance, Routing Context, Congestion Indications and 

INFO String are optional 

The parameter Affected point code is mandatory. 
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Section number in M3UA 
RFC 


Comments 


3.4.5 Destination User Part 
Unavailable (DUPU) 


The message is mandatory at the interfaces A and C. 

The parameters Network Appearance, Routing Context, and INFO String are optional. 

The parameters Affected point code and User/Cause are mandatory 


3.4.6 Destination Restricted 
(DRST) message 


This message is mandatory. 


3.5 ASP State Maintenance 
(ASPSIVI) IVIessages 


These messages are mandatory at the interfaces A and C. 


3.5.1 ASP Up message 


The ASP Identifier and Info String parameters are optional 


3.5.2 ASP Up 

Acl<nowledgement 

IVIessage 


The Info String parameter is optional. 


3.5.3 ASP Down message 


The Info String parameter is optional. 


3.5.4 ASP Down 
Acl<nowledgement message 


The Info String parameter is optional. 


3.5.5 Heartbeat message 


The message is mandatory. 


3.5.6 Heartbeat 
Acl<nowledgement message 


The message is mandatory 


3.6 Routing Key 
IVIanagement messages 


These messages are optional at the interfaces A and C. 


3.7 ASP Traffic IVIaintenance 
(ASPTIVI) IVIessages 


These messages are mandatory at the interfaces A and C. 


3.7.1 ASP Active message 


The parameters Traffic Mode Type, Routing Context and INFO String are optional. 


3.7.2 ASP Active 
Acknowledgement message 


The Traffic Mode Type, Routing Context and INFO String are optional. 


3.7.3 ASP inactive message 


The parameters Routing Context and INFO String are optional. 


3.7.4 ASP Inactive 
Acknowledgement 


The parameters Routing Context INFO String are optional. 


3.8 IVIanagement (MGMT) 
IVIessages 


Heading 


3.8.1 Error message 


The message is mandatory at the interfaces A and C 


3.8.2 Notify message 


The message is optional at the interfaces A and C 


4 Procedure 


The application of a particular procedure at a certain interface is detailed in the following 
sections 


4.1 Procedures to Support 
the IVI3UA-User 


Heading 


4.1 .1 Receipt of Primitives 
from the M3UA-User 


The procedure is mandatory at the interfaces A and C. 


4.1 .2 Receipt of Primitives 
from the Layer IVIanagement 


This section is outside the scope of this annex. 


4.2 Procedures to Support 
the Management of SCTP 
Associations 


The procedures are mandatory at the interfaces A and C 


4.2.1 Receipt of M3UA Peer 
Management Messages 


The two first paragraphs are outside the scope of this annex. 
Last paragraph is mandatory. 


4.3 AS and ASP State 
Maintenance 


The procedure is mandatory at the interfaces A and C. 
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Section number in IVI3UA 
RFC 



Comments 



4.3.1 ASP States 



Replace figure in section 4.3.1 in "RFC 4666" with tlie one below, wliich is based on 
figure 4 in draft-ietf-sigtran-m3ua-implementors-guide-01 



Other P^ 
in A3 
overides 



ASP active 



fSP- Active ^ 

I 

XSP- Active Ack 



H 

ASP- down 
ASP- Down Ack 
3CTP CDI 
SCTP RI 



ASP-Inactive 
ASP-Inactive Ack 



ASP inactive 



^i=i3P-UP 
ASP- UP Ack 



Optional 
Mandatory 



ASP-down 
ASP-DownAck 
SCTP CDI/SCTP RI 



ASP down 



4.3.2 AS States 



l\/landatory 



4.3.3 IV13UA IVlanagement 
Procedures for Primitives 



This section is outside the scope of this annex. 



4.3.4 ASPM Procedures for 
Peer-to-Peer Messages 



Heading 



4.3.4.1 ASP Up Procedure 



This procedure is mandatory at the interface C and is a subset of the procedure used at 
interface A. See also 4.3.4.1 .2. 

Note: The registration procedure is optional. 

A received ASP Up must be acknowledged by an ASP Up Ack message, if no restriction 
applies e.g. maintenance. 



4.3.4.1.1 M3UA Version 
Control 



This procedure is mandatory at the interfaces A and C. 
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Section number in M3UA 
RFC 


Comments 


4.3.4.1.2 IPSP 
Considerations 
(Asp Up) 


This procedure is mandatory at tlie interface A. 

The present section 4.3.4.1 .2 in RFC 4666 is replaced by: 

"An IPSP may be considered in the ASP-INACTIVE state after an ASP Up or ASP Up 
Ack has been received from it. An IPSP can be considered in the ASP-DOWN state after 
an ASP Down or ASP Down Ack has been received from it". 

The IPSP may inform Layer Management of the change in state of the remote IPSP 
using IVI-ASP_UP or M-ASP_DN indication or confirmation primitives. 

If for any local reason (e.g., management lockout) an IPSP cannot respond to an ASP 
Up message with an ASP Up Ack message, it responds to an ASP Up message with an 
Error message with reason "Refused - Management Blocking" and leaves the remote 
IPSP in the ASP-DOWN state." 

The paragraphs above are in accordance with changes included in 
Draft-ietf-sigtran-m3ua-implementors-guide-01 

All comments applicable for section 4.3.4.1 and 4.3.4.2 are also applicable for this 
section. 


4.3.4.2 ASP-Down Procedure 


This procedure is mandatory at the interface C and is a subset of the procedure used at 
interface A. See also 4.3.4.1 .2. 

A received ASP Down message must be acknowledged by an ASP Down Ack message, 
if no restriction applies eg maintenance reason. 


4.3.4.3 ASP Active 
Procedure 


This procedure is mandatory at interface C and is a subset of the procedure used at 
interface A. See also 4.3.4.3.1. 

Configuration data define which AS an ASP is a member of. The ASP Active message 
does not contain a Routing Context parameter. Consequently, the ASP Active Ack 
message does not include any Routing Context(s) parameter. 

The traffic state an ASP has, is configured within the associated Application Server. If 
more than one physical entity (ASPs, SGPs or IPSPs) implements a logical entity (SG, 
AS) then loadshare with 1 -i-k is the mandatory traffic mode. 

A received ASP Active must be acknowledged by an ASP Active Ack message, if no 
restriction applies e.g. maintenance reason. 

If a Routing Context parameter is included in the ASP Active message it is not needed 
to include the Routing Context parameter in the ASP Active Ack message. 

Note: This is a deviation to RFC 4666. 


4.3.4.3.1 IPSP 
Considerations (ASP Active) 


This procedure is mandatory at the interface A. 

Section 4.3.4.3.1 in RFC 4666 is replaced by: 

"Either of the IPSPs can initiate communication. When an IPSP receives an ASP Active, 
it should mark the peer as ASP-ACTIVE and return an ASP Active Ack message. An 
ASP receiving an ASP Active Ack message may mark the peer as ASP-Active, if it is not 
already in the ASP-ACTIVE state." 

The paragraph above is in accordance with changes included in 
Draft-ietf-sigtran-m3ua-implementors-guide-01 

All comments applicable for section 4.3.4.3 are also applicable for this section. 
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Section number in I\/I3UA 
RFC 


Comments 


4.3.4.4 ASP Inactive 
Procedures 


This procedure is mandatory at the interface C and is a subset of the procedure used at 
interface A. See also 4.3.4.4.1. 

Configuration data defines which AS an ASP is a member of. 

It is optional to send several ASP Active Ack messages in response to a single ASP 
Active message. 

A received ASP Inactive must be acknowledged by an ASP Inactive Ack message, if no 
restriction applies e.g. maintenance. 

The sending of Notify message is mandatory If the As state is changed. 


4.3.4.4.1 IPSP 
Considerations (ASP 
Inactive) 


This procedure is mandatory at the interface A. 

Section 4.3.4.4.1ln RFC 4666 is replaced by: 

"An IPSP may be considered in the ASP-INACTIVE state by a remote IPSP after an 

ASP Inactive or ASP Inactive Ack message has been received from it." 

The paragraph above is in accordance with changes included in 
Draft-ietf-sigtran-m3ua-implementors-guide-01 

All comments applicable for section 4.3.4.4 are also applicable for this section. 


4.3.4.5 Notify Procedures 


The procedure is mandatory at the interfaces A and C to reflect an AS state change. 


4.3.4.6 Heartbeat Procedures 


The procedure is optional. 


4.4 Routing Key 
management procedure 


The procedure is optional. 


4.5 Procedures to Support 
the Availability or Congestion 
Status of SS7 
Destination 


Heading 


4.5.1 AtanSGP 


Note; The use of Transfer restricted message is a national option and is about the scope 
of this specification. 

If the SG knows that the ASP support s DRST, then SG shall 

Send a DRST message, if the SG does not know whether the ASP supports the DRST 
message the SGW shall send a DAVA message if the destination earlier was 
unavailable. If the destination was available then no action is required. 


4.5.2 At an ASP 


Heading 


4.5.2.1 Single SG 
Configurations 


It is mandatory for an ASP to interoperate with one Signaling Gateway. 


4.5.2.2 Multiple SG 
Configurations 


It shall be possible to configure an ASP to handle at least a configuration consisting of 
two Signalling Gateways. 


4.5.3 ASP Auditing 


Only the part related to international use in Q.704 is inside the scope of this annex. 

Add the following paragraph to the corresponding section in RFC 4666 

"Where the SGP does not maintain the congestion status of the SS7 destination (ITU 
international networks), the response to a DAUD message should always be only a 
DAVA, or DUMA message as appropriate." 

The paragraph above is an extract from "draft-ietf-sigtran-m3ua-implementors-guide-01". 


4.6 MTP 3 restart 


The procedure is mandatory. 


5. Examples of M3UA 
Procedures 


Descriptive text 


5.1. Establishment of 
Association and Traffic 
between SGPs and ASPs 


Note The procedures defined in the sub-sections to 5.1 are a subset of the procedures 
defined in section 5.5. 
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Section number in M3UA 
RFC 


Comments 


5.1.1 Single ASP in an 
Application Server ("1+0" 
sparing 


Descriptive text 


5.1.1.1 Single ASP in an 
Application Server ("1+0" 
sparing), No Registration 


The use of RCn is optional. 


5.1.1.2 Single ASP in 
Application Server ("1+0" 
sparing), Dynamic 
Registration 


The use of dynamic registration is optional. 


5.1.1.3 Single ASP in 
Multiple Application Servers 
(each with "1+0" sparing). 
Dynamic Registration (Case 
1 - IVIultiple Registration 
Requests) 


The use of dynamic registration is optional. 


5.1.1.4 Single ASP in 
Multiple Application Servers 
(each with "1+0" sparing). 
Dynamic Registration (Case 
2 - Single Registration 
Request) 


The use of dynamic registration is optional. 


5.1.2 Two ASPs in 
Application Server ("1+1" 
sparing) 


This procedure is optional. 


5.1.3 Two ASPs in an 
Application Server ("1+1" 
sparing, loadsharing case). 


The traffic mode parameter is optional in ASP-Active message 


5.1.4 Three ASPs in an 
Application Server ("n+k" 
sparing, loadsharing case) 


The procedure is optional. 


5.2 ASP Traffic Failover 
Examples 


Heading 


5.2.1 (1+1 Sparing, 
Withdrawal of ASP, Backup 
Override) 


The use of the procedure "backup override" is optional. 


5.2.2 (1+1 Sparing, Backup 
Override) 


The use of the procedure "backup override" is optional. 


5.2.3 (n+k Sparing, 
Loadsharing case. 
Withdrawal of ASP) 


The procedure is optional 


5.3 Normal Withdrawal of an 
ASP from an Application 
Server and Teardown of an 
Association 


The registration procedure is optional. Routing Contexts (RC) Is optional. 
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Section number in IVI3UA 
RFC 



Comments 



5.3.x Normal Withdrawal of 
the ASP from an Application 
Server (1+1 sparing) 
loadsharing and Teardown of 
Association 



3GP 



ASP 2 



A3P1 



ASP Inactive 

ASP Inactive Ack ► 

^ ASP Inactive 

I 

ASP Inactive Ack 

Notify 

Notify 



.ASP Down — 
■ ASP Down Ack ^ 



ASP Down Ack 



-ASP Down 



The figure is added for clarification. 



5.4. Auditing Examples 



Heading 



5.4.1. SG State: 
Uncongested/Available 



Descriptive text. 



5.4.2. SG State: Congested 
(Congestion Level=2) 
/Available 



Descriptive text. 



5.4.3. SG State: 
Unknown/Available 



Descriptive text. 



5.4.4. SG State: Unavailable 



Descriptive text. 



5.5 M3UA/MTP3-User 
Boundary Examples 



Heading 



5.5.1 At an ASP 



Heading 



5.5.1.1 Support for MTP- 
TRANSFER Primitives at the 
ASP 



Heading 



5.5.1.1.1 Support for l\/ITP- 
TRANSFER Request 
Primitive 



The procedure is mandatory at the interface A and C. 

This description is also applicable for an IPSP, so replace the abbreviation ASP with 

ASP/IPSP and SGP with SGP/IPSP 



5.5.1.1.2 Support for the 
MTP-TRANSFER Indication 
Primitive 



The support is mandatory at the interface A and C. 

This description is also applicable for an IPSP, so replace the abbreviation ASP with 

ASP/IPSP and SGP with SGP/IPSP. 



5.5.1.1.3 Support for ASP 
Querying of SS7 Destination 
States 



This procedure is mandatory at the interface C. 

The quering of congestion states is an optional national procedure and outside the 

scope of this annex. 



5.5.2 At an SGP 



Heading 



5.5.2.1 Support for MTP- 
TRANSFER Request 
Primitive at the SGP 



The procedure is mandatory at the interface C. 
Networl< Appearance is optional. 



5.5.2.2 Support for MTP- 
TRANSFER Indication 
Primitive at the SGP 



The procedure is mandatory at the interface C 
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Section number in IVI3UA 
RFC 



Comments 



5.5.2.3 Support for MTP- 
PAUSE, MTP-RESUME, 
MTP-STATUS Indication 
Primitives 



Heading 



5.5.2.3.1 Destination 
Unavailable 



The procedure is mandatory at the interface C 



5.5.2.3.2 Destination 
Available 



The procedure is mandatory at the interface C 



5.5.2.3.3 SS7 Network 
Congestion 



The procedure is mandatory at the interface C 



5.5.2.3.4 Destination User 
Part Unavailable 



The procedure is mandatory at the interface C and optional at the interface A. 



5.6 Examples for IPSP 
communication. 



Replace the section in RFC 3332 with the paragraph below 

This scenario shows a basic example for IPSP communication for the three phases of 
the connection (establishment, data exchange, disconnection). It is assumed that the 
SCTP association is already set up. 



IPSP-A 



IPSP-B 



ASP UP — 

— ASPUPAck- 

ASP Active - 

.ASP Active A ck 



-Data 



-ASP Inactive Ack 



-ASP Inactive Ack 



-ASP Down 



-ASP Down Ack 



The paragraph above is in accordance with changes included in Draft-ietf- 
sigtran-m3ua-implementors-guide-01 
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Annex B (Informative): 

The use of M2PA in 3GPP networks 

B.1 Scope 

This annex defines the appHcation of M2PA in 3GPP core networks as an option on interface B. The purpose of the 
Annex is to ensure the interoperability of different implementations of M2PA as used by different operators and 
vendors. This is achieved by: 

Clarifying certain concepts which are used in RFC 4165; 

Defining those features in RFC 4165 for which support is mandatory; 

Defining those features in the RFC 4165 for which support is optional; 

Defining those features in RFC 4165 which shall not be used; 

This specification is intended for interfaces between network domains. However, it can also be used inside one network 
domain, and constitutes, in that case, a minimum set of M2PA requirements to be supported between IP nodes and 
between SRP nodes in a 3GPP network. 



B.2 Introduction 



M2PA may be used between SRPs, i.e. interface B (refer to Figure 1 of Annex A). 
Figure 2 recommends how M2PA is used in a 3GPP IP based signalling network. 




Figure B2.1 : Use of M2PA in 3GPP core networics 



B.3 Protocol conformance to RFC 4165 

A minimum implementation shall support sections marked mandatory in the table below. It shall be possible to 
configure all implementations to interoperate (no error messages returned) with the minimum set. 

The table below makes comment to the sections in RFC 4165. In the comment column the following terms are used: 

Mandatory: When support of text in a section is marked mandatory: 
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o On an information element, message or message class, it means that a receiver shall understand the 
information element, message or message class and carry out the requested action. 

o For a procedure, it means that the procedure is mandatory to be carried out by the involved network 
elements. 

Optional: When support of the text in a section is marked optional the feature involved is only guaranteed to 
work between peer entities which are subject to a bilateral agreement between operators of those entities. If one 
end uses an optional information element and the other does not support it, then a silent discard takes place of an 
information element as a part of the message. This is described as part of the handling of the optionality in the 
table. 

- Excluded: This means that the feature shall not be used in a 3GPP environment 

Descriptive text means that the section does not include any requirements for this specification. 

Note: The word "heading" means that the section consists only of subordinate sections. 

The comments column also defines the behaviour of a minimum implementation if it does not support a message or an 
information element in a mandatory message. 
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Section number in M2PA RFC 


Comments 


Abstract 


Descriptive text 


1. Introduction 


Descriptive text 


1.1 Scope 


Descriptive text 


1.2 Terminology 


Descriptive text. 


1 .3 Abbreviations 


Descriptive text. 


1 .4 Conventions 


Descriptive text. 


1 .5. Signaling Transport Architecture 


Descriptive text 


1.5.1 Point Code Representation 


Mandatory 


1 .6 Services Provided by IVI2PA 


Descriptive text 


1 .6.1 Support for MTP Level 2 / MTP Level 3 Interface Boundary 


Mandatory 


1 .6.2 Support for Peer-to-Peer Communication 


Mandatory 


1 .7. Functions Provided by M2PA 


Heading 


1.7.1 MTP2 Functionality 


Descriptive text 


1 .7.2 Mapping of SS7 and IP Entities 


Mandatory 


1 .7.3 SCTP Association Management 


Mandatory 


1 .7.4 Retention of MTP3 in the SS7 Network 


Descriptive text 


1 .8. Definition of the M2PA Boundaries 


Heading 


1 .8.1 Definition of the M2PA/MTP LevelS Boundaries 


Descriptive text 


1 .8.2 Definition of the Lower Layer Boundary between M2PA and SCTP 


Descriptive text 


1.9. Differences Between M2PA and M2UA 


Descriptive text 


2. Protocol Elements 


Mandatory 


2.1 Common message header 


Mandatory 


2.1.1 Version: 


Mandatory 


2.1.2 Spare 


Mandatory 


2.1.3 Message class 


Mandatory 


2.1.4 Message Type 


Mandatory 


2.1.5 Message Length 


Mandatory 


2.2 M2PA Header 


Mandatory 


2.2.1 Backward Sequence Number (BSN) 


Mandatory 


2.2.2 Forward Sequence Number (FSN) 


Mandatory 


2.3 M2PA Messages 


Mandatory 


2.3.1 User Data 


Mandatory 


2.3.2 Link Status 


Mandatory 


2.3.2.1 Link Status Proving 


Mandatory 


3 State Control 


Heading 


3.1 SCTP Association State Control 


Descriptive text 


3.2 M2PA Link State Control 


Descriptive text 


4 Procedures 


Mandatory 


4.1 Procedures to Support MTP2 Feature 


Heading 


4.1.1 Signal Unit Format, Delimitation, Acceptance 


Descriptive text 


4.1.2 MTP and SCTP Entities 


The content about how M2PA relates MTP 
and SCTP entities is Descriptive text. 

The relationship between the streams of 
SCTP and M2PA Messages is mandatory. 


4.1.3 Link Alignment 


The procedure is Mandatory. 


4.1 .4 Processor Outage 


Mandatory 


4.1.5 Level 2 Flow Control 


Mandatory 


4.1.6 Link Out of Service 


Mandatory 


4.1 .7 SCTP Association Problems 


Mandatory 


4.1.8 Transmission and Reception Priorities 


Mandatory 


4.1 .9 M2PA Version Control 


Mandatory 


4.2. Procedures to Support the MTP3/MTP2 Interface 


Heading 


4.2.1 Sending and Receiving Messages 


Mandatory 


4.2.2 MTP3 Signaling Link Congestion 


Mandatory 


4.2.3 Changeover 


Mandatory 


4.2.3.1 Multiple User Data Streams and Changeover 


Descriptive text 


4.3 SCTP Considerations 


Descriptive text 


4.3.1 SCTP Slow Start 


Descriptive text 

Avoiding the negative effects of slow start 
is Mandatory. 
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Section number in M2PA RFC 


Comments 


5 Examples of M2PA Procedures 


Descriptive text 


5.1 Link Initialization (Alignment) 


Descriptive text 


5.2 IVIessage Transmission and Reception 


Descriptive text 


5.3 Link Status Indication 


Descriptive text 


5.4 Link Status Message (Processor Outage) 


Descriptive text 


5.5 Level 2 Flow Control 


Descriptive text 


5.6 MTP3 Signaling Link Congestion 


Descriptive text 


5.7. Link Deactivation 


Descriptive text 


5.8 Link Changeover 


Descriptive text 
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